home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93a.txt / 000027_icon-group-sender _Mon Jan 18 13:52:51 1993.msg < prev    next >
Internet Message Format  |  1993-04-21  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 18 Jan 1993 07:55:00 MST
  2. Date: Mon, 18 Jan 1993 13:52:51 +0100
  3. From: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber)
  4. Message-Id: <9301181252.AA17972@soir.informatik.uni-tuebingen.de>
  5. To: icon-group@cs.arizona.edu
  6. In-Reply-To: (Michael Glass)'s message of Fri, 15 Jan 93 05:23:00 +0100 
  7.  <14JAN199323230672@adcalc.fnal.gov*MAILER@cdc2-gw.rrzn.uni-hannover.de>
  8. Subject: Pattern matching in Icon?
  9. Status: R
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12.  
  13. Well, at least one person got it (partially) right.  I had't
  14. thought of Prolog as the inspiration for the control structure
  15. I had proposes, but in fact, a unification is what would happen
  16. in pattern matching, albeit in a much more limited sense, that
  17. is also easier and more straightforward to implement.
  18.  
  19. As I keep saying (jeez, has NOONE here ever looked at Hope, Miranda,
  20. ML or the like?!), the proposed scheme could be used to
  21. implement structural recursion VERY elegantly - with the
  22. added power of generators.
  23.  
  24. Steve Wampler proposed ...
  25.  
  26. >I guess the only real debate is whether to add it into the language
  27. >or not:
  28. >
  29. >   case s := <expression> of {
  30. >      match_syntax_tree(s,"let") : {a := s.arguments
  31. >        ...
  32. >      }
  33. >
  34. >   ...
  35. >
  36. >   procedure match_syntax_tree(s, op)
  37. ># match a pattern, in this case, the pattern is simple...
  38. >      if type(s) == "syntax_tree" & s.operator == "let" then
  39. >         return s
  40. >   end
  41. >
  42. >or, though I find this less readable:
  43. >
  44. >   case s := <expression> of {
  45. >       1(match_syntax_tree(s,"let"), a := s.arguments) : {...
  46. >       ...
  47. >
  48. >not as visually pleasing as a new syntax would be, but I contend
  49. >this would be more flexible and generalizes better than fixed
  50. >patterns would...
  51.  
  52. This stuff looks extremely awkward to me, in fact even more awkward
  53. than doing the pattern matching explicitly.  It would mean having
  54. separate procedures (with different names, too!) for each constructor
  55. AND combination of constants/unknowns.  My proposal was exactly
  56. aimed at removing that syntactic clumsiness.  As I said (again,
  57. and again), that's exactly why compilers are so much easier to
  58. write and read in functional languages.  The way to go would
  59. probably be using the variant translator feature of Icon to do
  60. the job.  Anyone interested?  (If I'm not all alone with this, I
  61. might actually get around to doing it, some day ...)
  62.  
  63. Cheers :-> Chipsy
  64.  
  65.  
  66.  
  67.